Callbacks are asynchronous mechanisms used in a client-server environment for a network server to return services or information requested by a client. However, callbacks are not easily accomplished in a services oriented environment because the client who is requesting the service and the network server that provides the service may not be located within the same network domain. In addition, their communication may be restricted in a complex yet common case by firewalls or because the client may not have a fixed Internet Protocol (IP) address or its IP address may be translated through Network Address Translation (NAT) by an intermediate server or a combination of these common mechanisms.
FIG. 1 depicts a prior art of a network 104 supporting a client-server configuration. The clients 106 can request services and information from a remote network server 102. When the request is synchronous, the network server 102 delivers the result on the same connection between the client and the network server. When the request is asynchronous, the network server 102 makes a new connection to the client 106 to deliver callback results.
For example, a client requiring an asynchronous callback can register with a web service using Simple Object Access Protocol (SOAP) over HyperText Transfer Protocol (HTTP) message requests and asks for services that provide a client notification operation. To get callback results the client has to continuously poll the network server with messages (assuming that the network server maintains state for the registered client) to check for callback results or run a web service engine accessible by the network server to send a SOAP message back with the callback results.
Polling is inherently slow. The situation is further undesirable when polling has to take place across the Internet, because the polling increases unnecessary network traffic and further slows down the communication. Further, some applications might require immediate notification once the results of a call become available via callback, and higher polling frequency would be required for this situation. High polling frequency worsens the problem of additional unnecessary network traffic and subsequent congestion. Moreover, constant polling by clients reduces the efficiency of the network server because it has to spend Central Processing Unit (CPU) cycles to accept a polling request, to check its internal data structures to see if there is indeed a response for that particular client, and to produce a response to the polling request. Loss of the network server's efficiency prevents the network server from responding quickly to legitimate requests from new clients, which, in turn, restricts the scalability of the network server supporting callbacks. The worst polling scenario is when the response takes a long while to be generated on the network server but the client needs immediate notification of the response as soon as it is generated, which implies high frequency polling and a heavy load on the network server resulting from polling requests.
Alternatively, when the client registers for notification, it can leave behind an Universal Resource Locator (URL) address for the network server to send back a SOAP message to after the results become available as illustrated in FIG. 2. FIG. 2 is a prior art illustrating an asynchronous callback request from the client 106 to a network server 102 located remotely on the Internet. The client 106 sends a request 204 to the network server 102, whereby the request includes a callback network address (callback URL). The network server 102 delivers the response 214 to the network address specified by the client 106.
The other approach to handle asynchronous callbacks is to mount a web service engine on the client and to provide the client's URL address to the network server when the client registers for notification with the network server. However, FIG. 3 is a prior art illustrating this approach is inadequate if the client is behind a NAT/firewall 302, where the NAT/firewall 302 is a network isolation mechanism. Further, the current trend is to support thin clients, i.e., clients with limited resources, and the idea of running a web service engine on a client to support callback mechanisms is exaggerated and may restrict the users of a particular service.
However, leaving a URL address for return of SOAP messages on the network server, when the network server is not in the same network domain as the client as illustrated in FIG. 3 and when the client is not publicly accessible, causes problems, because the client can reach the network server but the network server cannot reach the client. FIG. 4 is a prior art illustrating callback problems for clients located behind a firewall 302. Client A 402 is a regular client that cannot be reached by an outside network server; client B 404 is a web server that is permitted to receive information from the outside network server due to firewall configuration; client C 406 is a web server but it is behind a NAT mechanism and not registered with a public domain name server (DNS) and hence inaccessible from outside the network domain. Callback 414 for client A 402 cannot be delivered because client A's callback URL is blocked by the firewall 302; callback 416 for client B 404 is delivered without any problem but this requires additional resources on the client B, which is an undesirable requirement for thin clients; callback 418 cannot be delivered because the callback URL is local to the network domain and hence not accessible from outside of the network domain.